OAuth 2.0

OAuth 2.0 是一个业界标准的授权协议（authorization protocol），与传统的登陆方式相比，增加了一个授权层来，客户端不是使用资源所有者的凭证来访问受保护的资源，而是获得一个访问令牌——一个表示特定范围、有效期和其他访问属性的字符串。经过资源所有者的批准，授权服务器将访问令牌颁发给第三方客户端。客户端使用访问令牌来访问由资源服务器托管的受保护资源。

角色介绍

• 资源所有者（Resource Owner）：顾名思义，资源的所有者，很多时候其就是我们普通的自然人（但不限于自然人，如某些应用程序也会创建资源），拥有资源的所有权。
• 资源服务器（Resource Server）：保存着受保护的用户资源。
• 应用程序（Client）：准备访问用户资源的应用程序，其可能是一个 web 应用，或是一个后端 web 服务应用，或是一个移动端应用，也或是一个桌面可执行程序。
• 授权服务器（Authorization Server）：授权服务器，在获取用户的同意授权后，颁发访问令牌给应用程序，以便其获取用户资源。

授权码模式

1. 用户在应用程序中，应用程序尝试获取用户保存在资源服务器上的信息，比如用户的身份信息和头像，应用程序首先让重定向用户到授权服务器，告知申请资源的读权限，并提供自己的 client id。
2. 到授权服务器，用户输入用户名和密码，服务器对其认证成功后，提示用户即将要颁发一个读权限给应用程序，在用户确认后，授权服务器颁发一个授权码（authorization code）并重定向用户回到应用程序。
3. 应用程序获取到授权码之后，使用这个授权码和自己的 client id/secret 向认证服务器申请访问令牌/刷新令牌（access token/refresh token）。授权服务器对这些信息进行校验，如果一切 OK，则颁发给应用程序访问令牌/刷新令牌。
4. 应用程序在拿到访问令牌之后，向资源服务器申请用户的资源信息
5. 资源服务器在获取到访问令牌后，对令牌进行解析（如果令牌已加密，则需要进行使用相应算法进行解密）并校验，并向授权服务器校验其合法性，如果一起 OK，则返回应用程序所需要的资源信息。

简化模式

应用程序运行在客户端，一个最大的变化就是其变成了公开应用程序（Public Client），应用程序的运行完全暴露在用户的控制之中。在这种场景下，应用程序是无法隐藏自己的一些敏感数据，比如 client id 和授权码，在这个方式下，再向授权服务器获取授权码是多此一举。为此 OAuth 2.0 提供简化模式，授权服务器在校验好用户信息后，直接颁发给应用程序访问资源服务器的访问令牌。换句话说，应用程序在获取访问令牌时无需提供授权码和 client id。

1. 用户在应用程序中，应用程序尝试获取用户保存在资源服务器上的信息，比如用户的身份信息和头像，应用程序首先让用户重定向到授权服务器，告知申请资源的读权限，并提供自己的 client id。在重定向的过程中，应用程序指定使用 Implicit Grant 授权方式。
2. 在授权服务器，用户输入用户名和密码，服务器对其认证成功后，提示用户即将要颁发一个读权限给应用程序，在用户确认后，授权服务器直接颁发一个访问令牌并重定向用户回到应用程序。
3. 应用程序在拿到访问令牌之后，向资源服务器申请用户的资源信息
4. 资源服务器在获取到访问令牌后，对令牌进行解析（如果令牌已加密，则需要进行使用相应算法进行解密）并校验，并向授权服务器校验其合法性，如果一起 OK，则返回应用程序所需要的资源信息。

应用授权模式

1. 应用程序尝试获取在资源服务器上的信息，应用程序直接向授权服务器申请访问令牌，告知申请资源的读权限，并提供自己的授信凭证（client id/secret）。在申请请求中，应用程序指定使用 client credentials 授权方式。在授权服务器，服务器对其 client credentials 校验成功后，授权服务器直接颁发一个访问令牌给应用程序。
2. 应用程序在拿到访问令牌之后，向资源服务器申请用户的资源信息
3. 资源服务器在获取到访问令牌后，对令牌进行解析（如果令牌已加密，则需要进行使用相应算法进行解密）并校验，并向授权服务器校验其合法性，如果一起 OK，则返回应用程序所需要的资源信息。

用户授权模式

在基本的授权码模式中，用户需要跳转到授权服务器上，使用用户名和密码登录后拿到授权码，然后把授权码交给应用程序，然后再去申请访问令牌。但有些时候，能否省去这个来回的跳转过程，把用户名和密码直接交给应用程序，让应用程序去申请访问令牌？

1. 用户在应用程序中，应用程序首先让用户到登录页面输入用户名和密码。
2. 应用程序拿到资源所有者的用户名和密码，加上自己的 client id/secret 一同向认证服务器申请访问令牌/刷新令牌。授权服务器对这些信息进行校验，如果一切 OK，则颁发给应用程序访问令牌/刷新令牌。
3. 应用程序在拿到访问令牌/刷新令牌之后，向资源服务器申请用户的资源信息。
4. 资源服务器在获取到访问令牌后，对令牌进行解析（如果令牌已加密，则需要进行使用相应算法进行解密）并校验，并向授权服务器校验其合法性，如果一起 OK，则返回应用程序所需要的资源信息。

这个授权流程被称为用户授信模式，其命名原因是由于应用程序是通过用户的授信凭证（比如：用户名和密码）向授权服务器申请访问令牌。 当应用程序换取到访问令牌之后，从安全的角度考虑，应用程序应该立即删除用户的授信凭证，不再保留。这也是 OAuth 2.0 所建议的安全规范，应用程序不应该通过用户的用户名和密码，而是应该都通过访问令牌去访问资源。